[Previous] [Next] [Index]
[Thread]
Barring Bros Was:Re: SLL protocol implementation ?
>It should be very straightforward -- either implementing purely from
>the protocol spec (http://home.netscape.com/info/SSL.htm) or licensing
>sslref (a low flat-fee arrangement -- contact me for more info if you're
>interested) are both viable and low-effort approaches.
It should be but it isn't! Your government has some peculiar export
license ideas :-(
SSL and S-HTTP/Shen are trying to do rather different things. SSL is trying
to secure the Web, S-HTTP is trying to build security into HTTP. Its a very
different character of security you get. One wouldn't look to using SSL to base
a payments scheme on.
Shen is a collevction of ideas of how to manage trust. Given the failure of
Barring bros yesterday placing limits on the exercise of certificates looks to
be very important.
We should look to create a stock market spec ASAP. The Barrings collapse could
have been prevented by attaching attributes to the certificate (cf PKCS certs).
The following is extrapolating the scheme I was looking at to make e-trade
work for an organisation like CERN.
Theoretical model:
The bank issues a master certificate which is signed by the board of the stock
exchange. This has the attribute "May sign another certificate with equal
effect". The Bank also place the stock exchange master certificate in their
personal trust hierarchy.
The Bank mints subcertificates for each of its traders, these may have
attributes of the type "Valid for transactions up to $10^6", "Valid provided it
is countersigned".
The losses of the bank with respect to any one trader are thus limited.
[Maths ommitted because it dosen't work in ascii]
Practical Model:
Real stock markets are more complex. Particularly with respect to selling
options where the losses are open ended. The set of attributes must be
determined to fit. The key point is that the attribute set must be given a fixed
semantics by all the parties. There are two main options here :-
1) The stock market board sets the attribute semantics.
2) Each company may define their own semantics.
(1) is easiest to implement, (2) is easiest to administer. What is actually
needed is a set of Meta semantics which allow the creation of a semantics which
fits the application.
Base Attribute types:
1) Purchase Limit.
2) Vendor Limit
3) Product restriction
Attribute Operators:
1) And
2) Or
3) Not
Meta Attributes:
1) Require countersignature.
2) Require notification after contract is struck
Algorithm Attributes
1) Allow particular signature algorithm to be used
2) Allow particular contract agreement protocol to be used.
So a certificate might be specific at the level of stating "this certificate may
be used to sell put options in gold to the value of $1000".
A market may be made more practical by allowing notifications to be made on a
probabalistic basis. "Inform this authority of the action at least 10% and no
more than 20% of the time. There could also be systems built in to deal with
fast markets when it would be advantageous to put the checking offline.
If people are interested I could put out a draft RFC PDQ. I'm interested in what
peoples ideas on a standard attribute set might be. If anyone has stock market
experience then it would be a big advantage.
Stock markets are the most demanding application for e-trade in many ways. They
are the simplest in one respect however. They are centralised and computerised
making introduction administratively easier than changing everyones credit card.
Phill Hallam-Baker
Follow-Ups:
References: